Skip to content

fix(server): release embedded runtime config listener - #3413

Open
ousamabenyounes wants to merge 1 commit into
different-ai:devfrom
ousamabenyounes:fix/issue-3321
Open

fix(server): release embedded runtime config listener#3413
ousamabenyounes wants to merge 1 commit into
different-ai:devfrom
ousamabenyounes:fix/issue-3321

Conversation

@ousamabenyounes

Copy link
Copy Markdown

Summary

  • release the embedded server's runtime-config listener when its handle stops
  • cover an in-process server replacement sharing the same runtime database
  • add an app-less Fraimz flow that executes the real lifecycle regression test

Why

  • a stopped embedded server kept its runtime-config subscription alive and could rewrite the shared generated OpenCode config from its stale workspace
  • that second writer made an identical provider PATCH appear file-changing and reloaded the engine
  • Related PR fix(server): return original config reference on no-op provider patch (#3321) #3349 improves no-op identity inside mergeRuntimeProviderUpdate, but the unchanged lifecycle regression test remains RED on its exact head (bb090e630cda81421af72d4b9188587032f76dea). This patch addresses the separate listener lifecycle that causes the file rewrite.

Issue

Scope

  • embedded managed-OpenCode server listener registration and shutdown
  • one server lifecycle integration test
  • one internal Fraimz proof flow and voiceover

Out of scope

Testing

Ran

  • bun test src/embedded-runtime-config-lifecycle.test.ts
  • pnpm --filter openwork-server typecheck
  • bun test (full server suite, compared with an identically provisioned origin/dev worktree)
  • pnpm fraimz --flow embedded-runtime-config-listener-lifecycle
  • real curl -X PATCH /runtime-config/providers after the two-server lifecycle setup

Result

  • targeted test: 1 pass, 0 fail
  • typecheck: pass
  • full server baseline: 597 pass, 10 skip, 4 fail, 1 error
  • full server patched: 598 pass, 10 skip, 4 fail, 1 error; identical pre-existing failure set plus the new passing test
  • Fraimz: PASSED, 1 passed, 0 failed, 0 skipped
  • curl response: changed:false, reload:"skipped"

Test verification (RED → GREEN)

Upstream origin/dev (3f9c38a37125450e9b11ff74061ed500626254c9) with only the new test:

expected { changed: false, reload: "skipped" }
received { changed: false, reload: "reloaded" }
0 pass
1 fail

The same unchanged test on PR #3349 (bb090e630cda81421af72d4b9188587032f76dea):

expected { changed: false, reload: "skipped" }
received { changed: false, reload: "reloaded" }
0 pass
1 fail

With this patch:

PATCH /runtime-config/providers 200
PATCH /runtime-config/providers 200
1 pass
0 fail

Reverting only apps/server/src/embedded.ts returns the test to the same RED failure.

CI status

  • pass: targeted lifecycle test, TypeScript typecheck, Fraimz runtime proof
  • code-related failures: none
  • external/env/auth blockers: the pinned local Bun container has the same four server-suite failures and one node:sqlite runner error on upstream and patched trees; no baseline passing test regressed

Manual verification

  1. Start and stop an embedded managed server against a shared runtime DB.
  2. Start a replacement server, patch a provider, then mutate the stopped workspace in that shared DB.
  3. Repeat the provider PATCH and observe HTTP 200 with changed:false and reload:"skipped".

Evidence

  • evals/results/2026-08-01T12-15-15-633Z/fraimz.html generated locally; every internal claim passed against the executed pinned-Bun integration test
  • video/screenshot: N/A — internal server lifecycle with no visible UI surface

Risk

  • low: the change only retains and invokes an unsubscribe callback already returned by the runtime-config helper
  • writes already queued before shutdown remain ordered by the existing per-path write queue, so the replacement server's later initial write lands last

Rollback

  • revert this commit; the previous behavior leaks the listener for the lifetime of the process

@vercel

vercel Bot commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
openwork-landing Ready Ready Preview, v0 Aug 1, 2026 12:20pm

@vercel

vercel Bot commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

@ousamabenyounes is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

openwork-server: no-op provider patch still reloads the engine (#3307 guard ineffective in production)

1 participant